-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http: add doc deprecation for private props #10941
http: add doc deprecation for private props #10941
Conversation
lib/_http_client.js
Outdated
@@ -182,7 +182,7 @@ function ClientRequest(options, cb) { | |||
'client'); | |||
} | |||
self._storeHeader(self.method + ' ' + self.path + ' HTTP/1.1\r\n', | |||
self._headers); | |||
self._headersStore); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe use a Symbol to hide it more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does accessing a value via a Symbol have a perf hit vs. normal property access in master?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. I'll look into making a benchmark.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Results with the following benchmark (is it worth adding to the repo?): targos@d50c790
# master
$ ./node benchmark/es/object-property-bench.js
es/object-property-bench.js millions=1000 method="property": 1,137.5161172810194
es/object-property-bench.js millions=1000 method="string": 1,133.78613592118
es/object-property-bench.js millions=1000 method="variable": 1,137.9577172760735
es/object-property-bench.js millions=1000 method="symbol": 1,133.090467628974
# v7.4.0
$ node benchmark/es/object-property-bench.js
es/object-property-bench.js millions=1000 method="property": 1,136.7741112855451
es/object-property-bench.js millions=1000 method="string": 1,136.7865674716409
es/object-property-bench.js millions=1000 method="variable": 1,135.1437992275612
es/object-property-bench.js millions=1000 method="symbol": 1,136.4064052769731
# v4.7.1
$ node benchmark/es/object-property-bench.js
es/object-property-bench.js millions=1000 method="property": 1,135.4850535131566
es/object-property-bench.js millions=1000 method="string": 1,134.4381133016345
es/object-property-bench.js millions=1000 method="variable": 78.62998231306928
es/object-property-bench.js millions=1000 method="symbol": 81.82481813228071
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so it might be worth sticking to properties for now.
As far as adding the benchmark, it could be useful. Although I'd probably put it in misc/ instead of es/ since it doesn't primarily deal with es6+ alternatives (which es/ seems to contain).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be worth sticking to properties for now
I don't think so. The numbers are very close and on multiple runs, the order varies a lot. It would be worth only for v4.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been testing this like crazy lately and from everything I have seen there is essentially zero perf impact from using symbols.
+1 to using a symbol instead. |
fd32784
to
16bd79c
Compare
@jasnell @targos Switched to symbol. CI: https://ci.nodejs.org/job/node-test-pull-request/6054/ |
Isn't this a major change? |
This PR needs at least one more approval from a @nodejs/ctc member in order for it to land (again, after #10805 lands). |
ce2aab4
to
953b97e
Compare
Updated PR to use one of the new http API methods and to reuse |
do we have any ecosystem usage metrics for this? that's my only concern before agreeing. |
@rvagg I don't know, all I can do is run in CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/586/
|
@ChALkeR are you still the one to find this data? |
P.S. I know I shouldn't have done this, but had some code that was function clearHeaders (res) {
res._headers = {}
res._headerNames = {}
} Obviously needs to change. Right now works on Node.js 8, but this landing will break even that without any warning. Should probably keep that working with a warning if the getters would keep working, right? |
@dougwilson Yeah I'm not sure what the best solution to that would be as far as the behavior of the setter, since we'd probably have to just copy the values out of the object instead of just using the same object reference (because the internal representation changed). Should we blindly copy values in the Thoughts on this @nodejs/collaborators ? |
I'll land this on Tuesday if there are no more objections before then. Here's another CI: https://ci.nodejs.org/job/node-test-pull-request/6720/ |
It looks like a lot of reverse compatibility work has been done here, can we get a redux of what won't work anymore after this change? |
I'm still a bit concerned with deprecating res._headers. Although it isn't documented as a public api, it is used in so many places. Is it really justifiable to break the ecosystem like this? |
@mikeal As far as I know there shouldn't really be any difference with the getters/setters in place. @evanlucas I don't understand the concern, there is no runtime deprecation anymore. It's a documentation deprecation. Also there are now other public http APIs that cover all of the use cases I've seen thus far for accessing the private properties. |
8126753
to
0cc96d1
Compare
@mscdex even with a docs only deprecation, that still more than likely means we are going to remove it eventually. I'm just not sure whether it is justified. I do seem to be in the minority on this one though so ¯\(ツ)/¯ |
@evanlucas Well yes, that is the plan for deprecations. I don't see how it's a problem considering it's only a docs deprecation for v8.0.0 and there are public methods that cover the current use cases for these private properties (these methods should be backported to v4.x and v6.x). IMHO there will be plenty of time for people to convert their code to use these new methods before the old, private properties become a runtime deprecation and eventually removed. This PR also fixes a backwards compatibility issue that currently exists in master, so that is why I've been wanting to get this landed sooner than later. |
0cc96d1
to
9be372f
Compare
A day late, but last CI before landing: https://ci.nodejs.org/job/node-test-pull-request/6759/ and last CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/633/ |
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
9be372f
to
8243ca0
Compare
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#10941 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This is one proposed solution to the current backwards compatibility issue (see #10558) in master with end users who directly access
outgoingMessage._headers
/outgoingMessage._headerNames
.This PR will be simplified some once #10805 is landed (which should land before this PR). Specifically, the
._headers
getter can simply just returnthis.getHeaders()
./cc @nodejs/collaborators
CI: https://ci.nodejs.org/job/node-test-pull-request/6054/
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)